Language/OS - Multiplatform Resource Library/LANGUAGE OS.iso/dsp/dspgroup/cis_dsp.arc/CIS_DSP2.TXT

Text File | 1988-04-27 | 98.9 KB | 2,373 lines

#: 71452 S17/TAPR NNC/DSP
    07-Mar-88  18:26:17
Sb: #Motorola DSP56001 price
Fm: Bob McGwier N4HY 74615,1366
To: ALL

Jane Bates, Marketing director of the Motorola DSP operation said that TAPR
could get the DSP56001 in lots of one or hundreds for $95 and that ANYONE
could get them for $125 a piece.
Bob N4HY


*** There is a reply:   71464

*** More ***

#: 71464 S17/TAPR NNC/DSP
    07-Mar-88  21:47:23
Sb: #71452-Motorola DSP56001 price
Fm: Lyle Johnson, WA7GXD 76246,565
To: Bob McGwier N4HY 74615,1366

super. my information was from the moto publication "update" from sometime last
half of last year. obviuosly, they are coming down the curve on price! looks
good so far!

lyle

#: 71519 S17/TAPR NNC/DSP
    08-Mar-88  21:02:08
Sb: #Drawings
Fm: Lyle Johnson, WA7GXD 76246,565
To: DSP 1 Team

Today I gave Cris a seven-page set of notes, along with four pages of partially
complete schematics and a block diagram for the DSP 1 project. Copies were
mailed to Tom Clark, Bob McGwier, Skip Hansen, Dan Morrison, Chuck Green and
Eric Gustafson.

I also sent a copy of the TI Digital Signal Processing Applications Manual to
Skip.

Let me know what you think when you get the material!  I am anxious to get the
schematics completed and the board layout done for the first set of prototypes!

Lyle

*** There is a reply:   71549

*** More ***

#: 71549 S17/TAPR NNC/DSP
    09-Mar-88  01:51:00
Sb: #71519-Drawings
Fm: Bob McGwier N4HY 74615,1366
To: Lyle Johnson, WA7GXD 76246,565

Great!
Looking forward to it.  Speaking of projects needing work, we will most
likely know within two weeks if we have a ride for PACSAT next February.
There is a meeting with Arianespace tommorrow.
Bob

#: 71544 S17/TAPR NNC/DSP
    09-Mar-88  01:31:59
Sb: #71378-TI vs Motorola IV
Fm: Bob McGwier N4HY 74615,1366
To: Lyle Johnson, WA7GXD 76246,565

I cannot say that the silicon will be trivial to come by as I have
experience with a donation of two to our efforts.  If we make a product for
licensing and no one can get the hardware to manufacture it, then the
license isn't worth a half sheet of used toilet paper.  The software
development tools, the assembler, linker, and emulator do work.  I agree
that the "C" compiler has its shortcomings (not bugs, just lack of certain
features like who wants to code your IEEE floating point numbers in Hex?).
But all the code we want should be done in assembler.  The linker works
fine, the assembler works fine, the emulator works as well.  HOWEVER, before
I stake my life on these development tools, I want this hardware they have
donated to us to work so that we can do some code development and testing.
I threw out the previous message as an opinion as to which was the better
processor, not which was the better company.  This is an area in which I
have zero experience having always worked on end products.  I am spending
some of the AMSAT funds allocated to DSP to buy the remaining parts for
these boards.  I will keep you all informed.
On the TMS320C15 design work: I anxiously await the schematics.  I don't
understand the use of the A/D you proposed.  Your approach seems unnecessarily
complicated.  Why not just latch and read with an IN instruction?  I am sure
that I am missing something.  Please explain further.
Bob

#: 71657 S17/TAPR NNC/DSP
    10-Mar-88  20:50:57
Sb: DSP1 comments
Fm: skip wb6ymh 72345,1725
To: Lyle, dspers

Lyle:

I received the DSP1 package today and have some ideas:

Z80: Personally I'm all for the Z80 to do the house keeping, but I think we
should leave the TNC function out and let the Z80 handle the new applications.
I don't think we really want a TNC3.  I expect 90% of the users for the DSP1
already own one or more TNCs so the added cost is already spent.

If we do market this widget as including the TNC function I think it MUST be as
capable as the existing TNC2, i.e. a full 32k of EPROM 32k of RAM for the Z80
application.  I am afraid that providing less would be too much of compromise
to the TNC side.  The people aren't going to want to give up any of their
existing whistles to get new whistles.

BELL 202 INTERFACE: Personally I am not too bothered by not having a 202
interface.  Don't all "real TNC's" have a modem disconnect?  The 9600 baud
martinsat modem will not be able to use the 202 interface, neither will SSTV,
WEFAX, or any medium speed stuff we'll be coming up with.  An external TTL to
202 modem is an easy project which can be built directly out of the handbook.
There are already lots of guys building these for the Digicom 64 software.
(cont next msg)





#: 71658 S17/TAPR NNC/DSP
    10-Mar-88  20:51:55
Sb: #DSP1 comments (cont)
Fm: skip wb6ymh 72345,1725
To: lyle, dspers

APPLICATION PROGRAM LOAD: If we decide to go the lesser route without a Z80 I
think I have a scheme that may minimize the logic and cost somewhat.  How about
just interfacing a couple of cheap (slow) EPROMS directly to the 32010? This
would eliminate all of the logic used to isolate the RAM from the 32010 during
download as well as the circuitry that actually copies the EPROM data into the
RAM (about 10 chips and a crystal).

One downside is that the clock circuitry would be more complicated since it
would be required to run at multiple rates, slow while booting, and fast for
normal operation.  However the more complex clock generator circuitry might be
used to advantage by providing the clock-stretching circuitry for the AD7569
and 8254 (CTC?).  Subtract at least 2 chips of the potential savings.

The chip selection logic would also become more complex, but I think it would
still fit within the PAL.

Another downside is TWO EPROMS would be required at a minimum.  The twice the
EPROMS would of course hold twice the number of applications, but I doubt
that's much of a plus.  Subtract another chip (a big one) from the savings.
This leaves a possible savings of around 8 chips and a crystal.

This scheme would function as follows: 1. Initially following reset the chip
selection logic would to generate EPROM chip selects for all data reads and RAM
chip selects for all data writes.

2. The software in the EPROM would copy all program memory from EPROM to RAM.

(cont next msg)



*** There is a reply:   71683

*** More ***

#: 71683 S17/TAPR NNC/DSP
    10-Mar-88  23:15:52
Sb: #71658-DSP1 comments (cont)
Fm: Tom Clark W3IWI 71260,3640
To: skip wb6ymh 72345,1725

I haven't received my copy of the drawings yet. Maybe they will arrive
tomorrow. Hope they do since Bob will be here for the weekend for
the AMSAT BoD meeting, and sinc we are meeting with the AMRAD DSPers
Friday nite for beer 'n pizza.
Re the 2206/2211 BELL 202 interface. It is not true that all 'real
TNCs' have modem disconnect. Kantronics, TASCO and PRUG are three
that come to mind. The idea behind the 202 interface was that the
1200 baud AND SLOWER applications could plug into unmodified TNCs
making life a lot easier for the user. On HF I still use the AEA
PM-1 modem and have been very glad they put in the 2206/2211 circuitry.
What the hell -- it's only 2 itty bitty chips!


#: 71659 S17/TAPR NNC/DSP
    10-Mar-88  20:52:36
Sb: #DSP1 comments (cont)
Fm: skip wb6ymh 72345,1725
To: lyle, DSPers


3. The software would strobe an output port at the end of the copy to disable
the EPROM.

4. The chip selection logic would generate RAM chip selects for all following
data reads (at full speed now).

I would connect 2 bits from "application selection" switch directly the high
order address lines EPROMs giving us 4 full sized applications.  Another 2 or 3
bits from the selector appear as input bits to the 32010 allow it to select
between multiple smaller applications within a 8K page of the EPROM.

If we provided RS-232 level conversion on one output bit and one input bit of
the general purpose digital I/O we could program a "bit banger" UART into one
of the "application areas" to implement a real cheap (and very dirty!) serial
download capability.  (CRAY replaces clip lead, news at 11:00).

I wonder if we might want to add a bar graph LED output port for a tuning
indicator?

On the penny pinching side the 16 position BCD coded switch at $4.00 plus $1
for a reset switch sounds expensive to me.  How about a 8 position Dip switch
'al la the TNC2?  Seems like cycling power would be good enough to select a new
program without the need for a separate front panel reset switch.  I am
assuming the function select switch is a infrequently used item similar to the
TNC2's baudrate switch.  If the switch is expected to be used frequently in
normal operations then it's worth the money.  I also don't see the need to
populate the modem disconnect connector with the TNC option, lets just make
provisions for it in the artwork.

I'm all for the $20 Ten Tec cabinet, it's money well spent.

I think there are enough valid technical reasons to go with PALS in this design
to avoid having to worry about the legal/paranoid/political issues of PALs.

73's all Skip WB6YMH




*** There is a reply:   71676

*** More ***

#: 71676 S17/TAPR NNC/DSP
    10-Mar-88  22:53:49
Sb: #71659-#DSP1 comments (cont)
Fm: Lyle Johnson, WA7GXD 76246,565
To: skip wb6ymh 72345,1725

Skip,

I appreciate the comments.  If we include the Z80, I am almost certain that
KISS code will appear at a minimum.  If we carefully define the interfaces and
commands, we could probably get Howie to make TNC 2 code port to the DSP 1.
But, as you say, do we really want a TNC 3?

If we only need a single timer, we can make one with 6 chips (HCT, cheap, low
power, 4 have 16 pins and 2 have 20 pins) that will cost a total of about $4.00
and not need the clock stretcher. It would be a write-only, 16-bit programmable
divider.

I like your idea about the bootstrap loader with slow EPROMs.  I have been
checking into 25 nSec class CMOS PALs (Lattice GALs, for example) And they are
in the $3.33 range for a 20-pin part with programmable registered outputs, etc.
The 24-pin PALs are about a dollar more.

Slow EPROMs are cheap, a bit-banger RS232 port may be viable (since it would
run from EPROM and all writes are to RAM, it doesn't take any space! Clever!).

I envision the 16-position switch as being used a lot (if we have the Z80
inside) to select various DSP/Z80 applications.

Seems we are looking at a fork in the road here.  Either toss in the Z80 and go
for gusto, or trim our sails as much as practical and still deliver a useful
DSP application project.  I guess, if we can trim the sails enough to drop the
end price into the $175 or less bracket, I can support it.

Saturday night Chuck and Dan are coming by to discuss things; I'll show them
your comments.

I appreciate the thoughtful input.  Keep it coming!

Lyle



*** There is a reply:   71699

*** More ***

#: 71699 S17/TAPR NNC/DSP
    11-Mar-88  10:51:12
Sb: #71676-DSP1 comments (cont)
Fm: Harold Price, NK6K 71635,1174
To: Lyle Johnson, WA7GXD 76246,565 (X)

I'd really hate to see us do a TNC3 with a DSP modem on the board. Especially
since the Z80 might have a tough time at the high end of the baud range.  The
z80 could handle 1200/300 fine, but HF is not a high-volume target, is it?
Let's do the cheapest effective DSP modem possible, and follow the real meaning
of KISS by keeping KISS out of it.  We need to reduce the cost, and reduce the
development time.  I can already see the same thing happening to the low-end
modem as happened to the TNC-2.  Lots of featureitess.  Remember all the fuss
to get something added to the TNC-2 so it would do AMTOR? Even seen anyone do
AMTOR on a TNC-2 (other than Paul?). hp

#: 71673 S17/TAPR NNC/DSP
    10-Mar-88  22:48:33
Sb: #71544-TI vs Motorola IV
Fm: Lyle Johnson, WA7GXD 76246,565
To: Bob McGwier N4HY 74615,1366 (X)

Bob,

The I/O on the DSP 1 is handled as you suggest.  I must have mis-stated
something.

The schematics I sent should help to clarify things.

I have gotten TONS of info from Moto and reps in the last few days on the
DSP56001 and on the new DSP96001/96002...  The 56001 looks like we could do
something very nice with.  I have it in the OrCad schematic library as a part
now!

I will leave it to the software folks to guide the decision on the chip for the
next project.  Too bad it isn't now, as I just passed on a SUPER deal on a pile
of 8k x 8 SRAMS, 40 nSec, skinny package, $6.00 price class.  Of course, with
its wider bus the DSP56001 will have offset some of the price advantage of
using slower memories by requiring more of them! Anyway, I have read the User's
Guide and am now studying the timing diagrams on the data sheet.

Will keep you posted!

Lyle




#: 71674 S17/TAPR NNC/DSP
    10-Mar-88  22:49:40
Sb: #71549-#Drawings
Fm: Lyle Johnson, WA7GXD 76246,565
To: Bob McGwier N4HY 74615,1366 (X)

The CPU project is still moving.  We got the 68-pin wire wrap sockets and the
32-pin ones.  Chuck's wire-wrap eforts are ongoning.  Hope to have some
additional details worked out soon in the design, and I need to consult some
with Mike Brock on it.

I think, if TAPR isn't funding a satelite, that we should set up a budget and
request TAPR funding to design the CPU and whatever radio portions are
appropriate.  I think we can get support for that.

Lyle



*** There is a reply:   71885

*** More ***

#: 71885 S17/TAPR NNC/DSP
    14-Mar-88  02:27:01
Sb: #71674-Drawings
Fm: Bob McGwier N4HY 74615,1366
To: Lyle Johnson, WA7GXD 76246,565

Please read what Tom and I have uploaded about AMSAT board and ignore the
easyplex as I will go back and tell Jan not to worry about the CPU.
Bob

#: 71724 S17/TAPR NNC/DSP
    11-Mar-88  19:40:22
Sb: #more comments on DSP1
Fm: skip wb6ymh 72345,1725
To: dsp'ers

Tom: No heart burn with the 202 modem, as long as it's not the only interface
and it's real estate doesn't shove something else more useful out.

Lyle: Received the DSP applications manual today, boy it's just chock full of
good stuff!  Sure wish the 32020 was cheaper, the wait line alone would really
make my application loader kluge a LOT easier!

#: 71807 S17/TAPR NNC/DSP
    13-Mar-88  02:08:17
Sb: #sample clock generation
Fm: skip wb6ymh 72345,1725
To: dsp

Lyle, a piece of your last message seems to have found it's way to the bit
bucket where you were talking about the sample clock.  Another chunk is missing
where you were discussing the bit-banger I/O.

I don't know what kind of control of the sample clock we need, I was assuming
exacting control was an application requirement.  If we do need finer control
than the binary chain can provide we might look at using a pair of 74ls592's
and a FF section to form a divide by N chain.  The ls592's would connect
directly to the 32010 data bus eliminating the need for latches and other glue.
An simple output port stobe would be all that is needed to load the divisor.
The input frequency could be DSP processor clock or clock/2 (max count freq is
20 Mhz).  With a 16 bit divide by N we could get down to 381 hz.  If a slower
clock frequency is available to start from (the Z80 perhaps) we might be able
to get by with a single ls592 forming an 8 bit divide by N.  What is the ideal
pulse width the A/D wants to see as a sample clock?  The /N would give a pulse
equal to one cycle of the input clock.

73's Skip



*** There is a reply:   71841

*** More ***

#: 71841 S17/TAPR NNC/DSP
    13-Mar-88  15:51:55
Sb: #71807-sample clock generation
Fm: Lyle Johnson, WA7GXD 76246,565
To: skip wb6ymh 72345,1725 (X)

SKip, the single pulse width should be just fine, I'll look at the data sheet,
but 150 nSec or so is what sticks in my mind as a minimum. Lyle

#: 71840 S17/TAPR NNC/DSP
    13-Mar-88  15:50:42
Sb: #TAPR DSP 1
Fm: Lyle Johnson, WA7GXD 76246,565
To: DSPers

Last night Chuck, Dan and I met and discussed DSP 1 at some length.  We are all
in agreement that the Z80 should be dropped and use the TMS32010 to bootstrap
itself via some shadow ROM arrangement.  KISS and all that.

Among other things, Dan would like to see traces and pads (but not necessarily
parts) for a full 16-bit input and 16-bit output parallel port with termination
SIP resistors and an IDC header, along with the capability for an external
clock (in case someone wanted to have a pair of these things doing some task so
they could be synchronized, for example), and have the INT, BIO and RESET lines
brought out.  Provision for a CPU watchdog should be considered and at least
traces and pads brought out for Tom's 2206/2211 "remodulator" circuit.  A
single channel 16-bit programmable timer based on '593 parts will be designed
and costed as well.

I will have more details of the discussions and, hopefully, some fairly
detailed block and schematics to send out in a week's time or so.

Keep the comments coming, the TAPR DSP 1 is going to be hot (and devoid of
creeping features while still very functional for numerous tasks)!

Lyle

*** There is a reply:   71889

*** More ***

#: 71889 S17/TAPR NNC/DSP
    14-Mar-88  02:27:36
Sb: #71840-TAPR DSP 1
Fm: Bob McGwier N4HY 74615,1366
To: Lyle Johnson, WA7GXD 76246,565

Glad I got my two cents worth in before that kind of decision is made.



#: 71868 S17/TAPR NNC/DSP
    13-Mar-88  23:00:22
Sb: DSP-1
Fm: Tom Clark W3IWI 71260,3640
To: Lyle

Lyle -- the schematics arrived Friday, just in time for us to discuss
the project at the AMSAT BoD meeting. Bob and I were pretty busy
this weekend, so neither of us have had time to prepare detailed
comments, but here are a few ideas/comments:
(1) We are ecstatic about the inclusion of the Z80 + 8530. This opens
up some incredible possibilities. However we are worried that only
having 8k RAM will be unduly limiting. The ROM data which is to be
loaded into the 3201x is needs only be 'visible' during the time
the 320 is being 'loaded'. Perhaps it could be 'shadowed' behind
32k of RAM so that we can have our cake and eat it too.
(2) I'll be ecstatic to give up the '202' port with the Z80 included!
(3) For several of the MO + DEM applications we have in mind, it
looks like a 32015 will be needed. The problem is that all our test
code to date has been MO or DEM but not both. With the 32010 having
its assymetric data RAM (128 words in the first page and only 16 words
in the second page), full duplex is going to be a real pain. Having
the second page a full 128 words long looks almost mandatory. Therefore
we think that we should shoot for the 32015.
(4) I haven't had time to review the schematics in detail. But here
are a couple of quick things I spotted:
  - I see no need for two 74F74 latches on BIO and INT (yes, I know you
    get two on one chip). BIO is the only one used in any of the
    current code.
  - I have at least one application that wants the A/D sample clock
    to come in from the outside world. At least provide a jumper
    disconnect between the CTC and the A/D.
(5) Re name: Instead of DSP-1, howz about  "DSP 2001" ?
73, Tom


#: 71869 S17/TAPR NNC/DSP
    13-Mar-88  23:01:04
Sb: HF Modem DSP
Fm: Tom Clark W3IWI 71260,3640
To: all

This note is to correct two errors I made in my earlier comments on
the m-ary OOK HF proposal, and to offer some additional ideas:
(1) I called it FSK and the correct term is OOK (on/off keying). Hell,
you've got to realize I am a dumb astronomer who understands fourier
transforms, but not communications jargon! In my world, it's all
noise anyway.
(2) I suggested that 32 (+FEC and pilot tone) channels spaced 20
Hz would accommodate 20 baud. I was off by a factor of two due to
goof in transcribing notes from the back of one envelope to another.
If I do an FFT on 1/20th of a second of data, adjacent bins are in
fact spaced 20 Hz. However the sin(x)/x sampling window goes from
the peak to its first zero 40 Hz (2 bins) away. Adjacent bins will
be unlikely to have enough amplitude discrimination, and the channel
spacing should be 2 bins.
Now for other comments -- Friday nite, N4HY and I met with several
of the DC area DSP enthusiasts over beer 'n pizza and spent considerable
time discussing the HF modem problems and possible alternatives. In
a prior incarnation Rick, WB2TNL had worked on a m-ary FSK modem at
a defense contractor and shared his experiences. Rick pointed out
that the peak-to-average power ratio required for m-ary coding was
pretty horrendous, and it may be that our xmtrs may not be up to
it (at some time, all the individual tone vectors do add up!). We
also discussed the ionosphere limits and several studies were cited
that proved my conjecture that signal elements shorter than 20 msec
(speed > 50 baud) will have problems under some real-world conditions.
We discussed alternatives and the m-ary FSK, despite its limitations,
still seemed the most fruitful avenue to investigation.
73, Tom


#: 71870 S17/TAPR NNC/DSP
    13-Mar-88  23:01:49
Sb: RE: HF Modem DSP #2
Fm: Tom Clark W3IWI 71260,3640
To: all

Now let me try on more idea on y'all just to be a heretic. Lyle's
DSP engine design has a Z80 in it and the Z80 has enough horsepower
to do the TNC job after it uploads the DSP code to the 32015. If
we are trying to improve HF performance, and we will be adopting some
wierd and wonderful new set of modem standards, then why don't we
also optimize the level-2  protocol also. In short -- why use AX.25?
   Here are a couple of ideas that came to mind:
(1) We have seen that when conditions are grubby, running shorter
PACLs (32, 64) gets more data thru. But when conditions are good, longer
PACLs (like 128) move data more efficiently. Just like p-persistent
CSMA adapts FRACK to changing conditions, how about an analogous
adaptive PACL? And of course the baud rate itself should adapt to
changing conditions too.
(2) Now for more heresy! How about using connectionless datagram
protocols. Here might be one way (based on a similar scheme used
to upload data to UoSAT) -- consider a 2048 byte message. Subdivide
it into 64 frames, each 32 bytes long. To each of these frames append
2 bytes of CRC+ some sort of identifiable frame separator + the framet
number (about 6 bytes extra). Now collect all 64 * (32+6) = 2240
bytes and send them in one burp.
  Some of the 64 frames will be received at the other end correctly,
and some won't because of QSB/QRM/QRN etc., but the receiver will
know which ones are good because of the CRCs in each frame. The receiver
sends back an 'ack' which is 8 bytes long (for this example). Each
of the 64 bits corresponds to one of the 64 frames, and is set to
a '1' if it has been received, 0 otherwise. The sender then sends
only the missing frames, and the cycle continues until the sender
receives a '11111111 111111111 ....' message from the other end.
   Note that this is not the only scheme which might be used --
I include it just as an example to stimulate other discussions.
73, Tom

#: 71919 S17/TAPR NNC/DSP
    14-Mar-88  16:59:47
Sb: #71840-TAPR DSP 1
Fm: David Toth VE3GYQ 72255,152
To: Lyle Johnson, WA7GXD 76246,565 (X)

Dear Lyle:
You all have forgotten a very important point.
If you remove the Z80 widget, this thing will only run if you connect it to a
tnc. For a small increase in price and parts, you can have this little box plug
into everything from a commode-door to an IBM ... in fact, you don't/won't have
to pug it into anything. It would stand alone, and that is what I thought we
were after in the first place. I would strongly advise against deleting the Z80
... in essence, keeping it IN would keep it simpler.

A lonely voice crying in the wilderness, Dr D

*** More ***

#: 71973 S17/TAPR NNC/DSP
    15-Mar-88  13:17:17
Sb: #71840-TAPR DSP 1
Fm: Barry McLarnon VE3JF 71470,3651
To: Lyle Johnson, WA7GXD 76246,565

I mentioned this some time ago but never got a response, so here goes again: is
there provision for multiple analog inputs and outputs in the DSP 1? As a bare
minimum, there should be provision for two inputs, to allow the board to do
multiple-receiver diversity combining, among other things.

Barry

#: 71933 S17/TAPR NNC/DSP
    14-Mar-88  21:00:15
Sb: DSP 1
Fm: Lyle Johnson, WA7GXD 76246,565
To: DSPers

There are currently two avenues of thought on the DSP-1 project.

One is to include a Z80 and an 8530, and go for gusto on the baseline unit. We
are looking at a sell price of about $225 up to maybe $250.

The second is to go to functional minimums, a sort of AEA PM-1 approach, and
with a sell in the $175 range.

We need to keep in mind that, after the DSP-1, there will be a DSP-2
(developer's board) project, based on the TMS320C25 or DSP56001 chips, that
will be a pedal-to-the-ketal al-out high-performance unit from which will
spring the DSP-3.  DSP-3 will be a standalone, no-holds-barred unit based on
the processor chosen for DSP-2 and with an 80186 or V40 class co-processor,
wide-bandwidth busses, etc.

The applications and purposes I see for DSP-1 are:

(a) put DSP technology into the Amateur community in a cost-effective manner to
educate Amateurs about the potential of DSP for communications (b) provide
support for martinsat and pacsat-a and phase-3-c and fo-12 and pacsat-b (c)
provide a configurable modem for HF higher-bit-rate low-baud-rate
experimentation (d) see if enough interest is generated to define a market
niche and license OEMs to pursue that niche.

(continued -->)


#: 71934 S17/TAPR NNC/DSP
    14-Mar-88  21:00:56
Sb: dsp 1 2 of 4
Fm: Lyle Johnson, WA7GXD 76246,565
To: DSPers

DSP-1 will necessarily be limited in scope and performance (8-bit resolution
analog front end, 32010 with 4k word program memory limit and 144/256 word data
memory limit).

I think we need to carefully consider how many folks are likely to buy such a
widget for which purposes, and what impact cost will have (is the market
elastic or inelastic with respect to price as my old economics professor was
wont to ask).

I have my own personal preferences, but I am only one Amateur.  I have my
preferences for Amateur digital satellites (I am working on that program) but I
couldn't vote my personal preferences when it came to TAPR funding; I had to
vote what I perceived the majority of th members would prefer, based on my
contacts with them and experiences over the last several years.

Having stated the above, I will now offer my opinions:

1) I would prefer that the baseline DSP-1 be as capable as practical.

2) In discussing DSP with non-technical hams that I come in contact with, I get
a very real sense of "what's DSP?" (like I used to hear "what's a packet?") and
I get a strong sense of cost sensitivity for another toy.  Lots of hams find a
hundred bucks a painful amount of money.

3) In discussing DSP with technicaly-oriented hams that I come in contact with,
I get a sense of wanting more and being willing to pay a little for it.

(continued -->)

#: 71936 S17/TAPR NNC/DSP
    14-Mar-88  21:01:34
Sb: dsp 1 3 of 4
Fm: Lyle Johnson, WA7GXD 76246,565
To: dspers

4) We sold 2,500 TNC 1s at $240 plus $70 plus s&H = $326 for a complete TNC 1.
No one complained about the price until the fire sale.  It was the only real
game in town at the time.

5) We sold 1200 TNC 2s in 12 weeks at $185 plus s&H = $195.  It was, of course,
the cheapest game in town at the time.

6) We will have a unique product.  The more it can do, the more it will be
worth. On the other hand, the cheaper it is, the wider the appeal it will have.

7) We will be following this product with another, far more advanced unit in
another year to year-and-a-half -- at a far higher (2 or 3 times) cost.

8) We must ask ourselves: what is this for?  When we know the answer to that,
we will know whether we are making a $175 PM-1 like device, or a $225-$250
PK-232-like device.  If the 9600 bps application requires a 32015, and the
other applications can be done in a 20 MHz 32010, then the $175 device becomes
a $1909 device with 32015 and a $165 device with a 20 MHz 32010.

9) We have DSP programmers in Tom and Bob and Dan.  Who is the Z80 programer
(remember the ides of the NNC...)?  And will he/she/they be willing to make
this thing do all the neat things we want to do in the Z80?

10) We want to have fun, not take pot shots at each other.

(continued -->)


#: 71937 S17/TAPR NNC/DSP
    14-Mar-88  21:02:09
Sb: #dsp 1 4 fo 4
Fm: Lyle Johnson, WA7GXD 76246,565
To: dspers

11) We won't all agree on what this will be or what it should do.

12) I suspect that if we make 500 DSP-1s, 200 will go to satellitepeople and
300 will go to non-satellite people (if the applications exist) for HF, FAX,
RTTY, CW, AMTOR, SSTV aplications.  If the only applications written are
satellite modems and HF packet modems, then I think it becomes 200 satellite
units and 50 non-satellite and only 250 produced.  The numbers may be off, but
I think the ratios are not without some basis.

If this is so, is it fair to make everyone pay another $50 for capability they
neither need nor want?  Or, is it fair to the others to delete the coprocessor
capability for a lousy $50?

13) I don't have the answers.  But we need bidirectional, rational discussions
and I think the first thing we need to have a sense of direction on is the list
of applications.

Lyle

*** There are replies:  71950, 71951

*** More ***

#: 71950 S17/TAPR NNC/DSP
    15-Mar-88  00:03:20
Sb: #71937-dsp 1 4 fo 4
Fm: Bob McGwier N4HY 74615,1366
To: Lyle Johnson, WA7GXD 76246,565 (X)

I agree on the applications needed to make it widely liked.  Lamb will claim
that to this day the addition of the WEFAX (not APT, HF) brought he PK-232
out of the doldrums and I bet not one in a hundred uses it.  I don't think
we can find out who is willing to do the microprocessor code until we ask.
I suggest we ask Mike Chepponis.  He paid $525 for the TMS320C10-25 board
from Delanco-Spry.  He wrote Kiss for the TNC-2.  He is my ideal candidate
of the perfect man to work with the DSP code writers.  We won't know until
we ask.  The TNC-2 code can surely be adapted to this if we think we and
Howie can get together on this work.  I can write RTTY, packet modems, etc.
but I don't have the foggiest notion of how to proceed with the Morse code
demodulator and much of that will have to be done in the GP micro to do look
up tables for speed versus weighting, etc.  I know how to do the WEFAX HF
and I have done the WEFAX APT.  I know how to do the SSTV and the only
question remaining to be answered is do I have enough clock ticks to process
the output, find the sync, etc. for a sufficiently high enough sample rate
to make frequency decisions do-able.
I would also like to disagree with myself (now you know I am losing it). I
so strongly disagree with the applicability of the firesale analogy that I
want us to be able to shout this from the rafters at Dayton. If we are going
to, time is short.  I will be in England the first half of April but the
applications we need to show it is real even I could write the code for.
Here is one thing we are forgetting.  The TMS320C15 is pin compatible with the
10 so we can have this as a chip replacment upgrade if we get to
applications.  We did this with 32K RAM chips and 1.1.X and the price is the
primary difference.  Go with a TMS320C10-25 rather than go to a slower clock
rate if you want to make a price trade off.  We can always replace the 10
with the 15 for the limited number of packet folks who want 9600 BPS modems
given that they will have to spend $$$ on the radio as well. Bob.


*** More ***

#: 71951 S17/TAPR NNC/DSP
    15-Mar-88  00:03:30
Sb: #71937-dsp 1 4 fo 4
Fm: Bob McGwier N4HY 74615,1366
To: Lyle Johnson, WA7GXD 76246,565 (X)

Re:12.
I also meant to add it will be exceedingly difficult to do those for
anything but an IBM PC (if I do it) if we don't have a GP u-processor.
Number 12 should sell everyone on the need for a GP - microprocessor.
We need it to make it the 300+200 scenario you mention.  I know this won't
sell TAPR folks but this will do RUDAK when it is turned on and it will do
Phase III-C (since it does RUDAK) telemetry demod as we can do the decoding
of the frames in the GP microprocessor.
I am only sorry that we turned you off on a 1X level board back when you
first wanted to do it.
Bob

#: 71947 S17/TAPR NNC/DSP
    14-Mar-88  23:13:23
Sb: TMS320C1X design
Fm: Bob McGwier N4HY 74615,1366
To: ALL

Having cooled off a little I would like to try and convince you to
reconsider the dropping of the additional processor on board the DSP card.
The cost to benefit ratio is the operant concept here.  I agree that after a
certain point, the desire will taper off but how many thousands bought
TNC-1's for the price range we are talking about and we will give them
everything a PK-232 does (with the exception of maybe Morse which frankly I
wouldn't even hazard a guess as to how to do the demod), with software
change-able modems so that the user will be able to change his modem to meet
the changing conditions or bands or radios.  Further if you will put a
TMS320C15 on it I can put up to 4800 BPS on the thing with adaptive
equalization and do it at 1200 Baud sampling at a lousy 9600 bps.  THAT IS
IF YOU DON'T take the extra microprocessor off of it.  This means I would
like the output path from the DSP to the microprocessor to be more flexible
than just through the 85C30 but I also want that.  I want it because I can
do 9600 BPS FSK WITH AN OPTIMAL RADIO DESIGN which I believe we should do
anyway to support this board, K9NG modem, and MartinSat.
As to the firesale, life is tough.  I can't tell you how much it takes to
get me to spend money on new computer equipment always fearing that
something new is around the corner.  I suggest that we give the
manufacturers plenty of warning and if that means Lyle doesn't get to toot
the horn at Dayton then so be it.  This is no reason for us to do less than
we might.  There should be no doubt in your minds that the manufacturers
want us.  Mike Lamb has approached us all directly.  Without exception, they
have ALL approached me in private. They want this product very badly.  You
are afraid of hurting folks with a firesale.  That analogy is so full of
shit I can't believe that I have to consider it.  We are not producing
another tnc.  I am not interested in producing another TNC.  This is a
multimode, multipurpose  communications center as well as several pieces of
test equipment.


#: 71948 S17/TAPR NNC/DSP
    14-Mar-88  23:13:38
Sb: #TMS320C1X part II
Fm: Bob McGwier N4HY 74615,1366
To: ALL

This thing can even be used to do spectral analysis on a blasted C-64.  The
spectra won't come very fast but they are just a transfer of bytes away from
the DSP-1 and the C-64.  I believe that I can even do SSTV with this thing if
you want to have the severe limitation of graphics in the PC.  On something
like the Amiga or Atari ST or even the COCO we could do much better. I didn't
finish my explanation of the need for the other microprocessor above.  On the
high bit per baud modem, it would be nice to unload the bit decision onto the
general purpose miroprocessor and leave the carrier tracking, EQ, and clock to
the TMS320C1X.  Tom and I discussed ways to really implement some of the ideas
that Barry, Tom, and I have discussed with you here, in Tuscon and in Barry's
articles in QEX in that with the general purpose microprocessor to change the
protocol used on HF as suggested by Barry and in Tom's missive yesterday is
still only a change of software in the Rom on board the DSP-1. Look if I can't
convince you that for FIFTY DOLLARS LESS than a PK-232 (unless the price has
gone up), what it does and more isn't a good enough cost to benefit ratio then
I have talked so much recently that folks just aren't listening. God help the
planet earth if we ever make a third generation box with a REAL microprocessor
on board it.  I know I sound like a preacher, I listen to my dad in the pulpit
for years in the heart of the bible belt, what do you expect? Bob N4HY



*** There is a reply:   71963

*** More ***

#: 71963 S17/TAPR NNC/DSP
    15-Mar-88  09:57:29
Sb: #71948-TMS320C1X part II
Fm: David Toth VE3GYQ 72255,152
To: Bob McGwier N4HY 74615,1366

Bob: I talked to a guy in Toronto with a ham store and he says the PK232
OUTSELLS everything so I guess folks will pay for features AND WANT THEM.

#: 71974 S17/TAPR NNC/DSP
    15-Mar-88  13:18:18
Sb: #71869-HF Modem DSP
Fm: Barry McLarnon VE3JF 71470,3651
To: Tom Clark W3IWI 71260,3640

Whoa!... what you said before (I just went back and looked) was that you could
do 40 baud with 20 Hz (i.e., 1/2T) spacing.  Now you're saying that for 20
baud, you need 40 Hz (2/T) spacing.  The minimum orthogonal spacing, as I've
pointed out before, is 1/T Hz.  Although the width of the sin (x)/x main lobe
is 2/T, the distance from the peak to the first zero is 1/T, or 20 Hz away (not
40) in the example you cited.

Anyway, let's get back to deciding what are objectives are.  M-ary FSK is great
for making a relatively robust low-speed modem, but the problem is that the
bandwidth required grows exponentially with bit rate.  If we take 50 baud (T =
20 ms) to be the maximum acceptable baud rate, then with 32-ary signalling we
have 5 bits/baud, or only 250 bps.  To get to 300 bps, we need 64 tones, and at
50 Hz spacing, we're already occupying more than the voice band!  Not an
attractive proposition.  On the other hand, in an FDM approach with a large
number of simultaneous tones, the required bandwidth grows linearly with bit
rate, but we have that nasty peak-to-average ratio problem. Looks like time for
a compromise.  How about transmitting just two simultaneous tones (good grief,
DTMF!)?  Suppose we have 16 possible tone frequencies, with 50 Hz spacing/50
baud transmission rate (and a fairly "respectable" bandwidth of around 800 Hz).
There are (16*15)/2 = 120 possible tone pairs, so we judiciously choose 64 of
them to be valid, giving us a throughput 6*50 = 300 bps.  The demodulated
codeword is the one with the highest correlation with the FFT of the received
symbol.

If we're shooting for 1200 bps, on the other hand, there seems to be no way of
avoiding having a signal with high peak-to-average ratio (let's call it PAR for
short), unless, of course, somebody wants to try designing a fast adaptive
equalizer. :-)

73, Barry


#: 71975 S17/TAPR NNC/DSP
    15-Mar-88  13:19:11
Sb: #71870-RE: HF Modem DSP #2
Fm: Barry McLarnon VE3JF 71470,3651
To: Tom Clark W3IWI 71260,3640

Heck, that ain't heresy... just good ole common sense!  It stands to reason
that if we want to squeeze the most out of the HF channels as far as data
throughput is concerned, we have to dump the excess baggage that comes with
AX.25 L2 connections.  While we're at it, we need to disabuse folks of the
notion that CSMA can function properly on HF channels.

I like the idea of long datagrams with small subpackets, each with their own
CRC, coupled with a selective-reject ARQ protocol.  In fact, this is the
essence of the scheme I outlined in my Jan.'88 QEX article (y'all read it,
didn't you?).  Since the overhead is small, there would be no need to adapt the
packet/subpacket lengths, and there is also the possibility of doing
soft-decision decoding tricks such as memory ARQ.

Now for some real heresy.  Let's dump HDLC!  We want a preamble that aids
robust clock recovery, not HDLC flags, and HDLC bit-stuffing gets in the way of
framing up the data so that we can do our signal processing tricks.  Also, we
should have frame sync sequences that are designed for good auto- and
cross-correlation properties... HDLC flags aren't.  How about using Bi-Sync
instead?  The standard SIO hardware can still be used, but we would need some
new firmware (HF-KISS?) for the TNC.  And, while we're at it, lets get rid of
NRZI in favor of a baseband coding scheme that has better self-clocking
properties.  Manchester takes too much bandwidth, so I nominate Delay
Modulation (Miller code), which has roughly the same bandwidth as NRZ and
guarantees that no more than one-bit interval passes without a level
transition.

That should give ya something to chew on for awhile...

73, Barry

#: 71989 S17/TAPR NNC/DSP
    15-Mar-88  15:15:22
Sb: z80
Fm: skip wb6ymh 72345,1725
To: dsp'ers

Bob: please don't misinterpret enthusiasm and a difference of opinion for an
conspiracy.

All: I for one am willing to write software for the lowly Z80.  I wrote a
commercial packet application for the TNC2 using a hex monitor on the TNC and a
cross assembler on my AT.  Development tools for assembler are not lacking for
the Z80, high level languages are a different story! If we are talking about
significant amounts of new code for the GP micro I think we should look at the
cost of a minimum 80xxx family system to avoid the NNC software syndrome.  We
also should keep in mind going with anything other than a Z80 family chip will
not allow the existing applications for the TNC2 to be easily ported since they
are written in assembler.

#: 71991 S17/TAPR NNC/DSP
    15-Mar-88  16:51:56
Sb: #71937-dsp 1 4 fo 4
Fm: Barry McLarnon VE3JF 71470,3651
To: Lyle Johnson, WA7GXD 76246,565

Seems to me the easiest way out is to provide the pads on the board for all the
goodies, and allow the end user to choose whether to spend the extra bucks to
fill the extra sockets and/or put in higher-speed parts if he wants to run the
high-end applications.  The 320C15 is no problem - you just pays the extra $$$
and plugs it in.  So, make a board that can be plain vanilla or tutti fruiti,
depending on what you stuff it with (I'm not suggesting pads for 320C25's and
the like, just the coprocessor and other stuff you've mentioned as
possibilities for the DSP 1).

As Bob mentioned, some of the HF modulation/coding/protocol ideas we are
currently kicking around will necessarily involve offloading some of the
not-so-DSP stuff onto a g.p. processor (+ associated comms hardware).  This
could be in a separate TNC, but would be a lot tighter and neater if it was on
the DSP board.

Barry

#: 72011 S17/TAPR NNC/DSP
    15-Mar-88  21:58:52
Sb: #71973-TAPR DSP 1
Fm: Lyle Johnson, WA7GXD 76246,565
To: Barry McLarnon VE3JF 71470,3651 (X)

Barry,

Only one port planned at this time. However, a full, independent parallel in
and out port will likely be in place, to which a second analog port could
easily be interfaced.

Lyle


#: 72012 S17/TAPR NNC/DSP
    15-Mar-88  21:59:43
Sb: #71974-#HF Modem DSP
Fm: Lyle Johnson, WA7GXD 76246,565
To: Barry McLarnon VE3JF 71470,3651 (X)

Barry, Tom,

One thing that hasn't been discussed here is the issue of suitable IF filters
for available HF radios.  If the HF modem design calls for 1 kHz bandwidth, and
the user is then forced to use a 1.8 kHz or 2.4 kHz filter, his AGC is gonna
get pumped by somebody else, and the data may well get flushed as a result.
Eric's HF tests reported in PRM a year ago brought this to light rathr vividly.

And, 1 kHz isn't to be found on, say, 40 meters (although 600 Hz is). Available
filters seem to be 600 Hz, 1.8 kHz, and 2.4 kHz.

Just thinking (and talking some with Dan...),

Lyle



*** There is a reply:   72024

*** More ***

#: 72024 S17/TAPR NNC/DSP
    15-Mar-88  23:35:16
Sb: #72012-#HF Modem DSP
Fm: Tom Clark W3IWI 71260,3640
To: Lyle Johnson, WA7GXD 76246,565 (X)

Lyle, most of the modern radios have some sort of PBT option. On
my TS940, I find that its skirts work quite well to prevent QRM from
clobbering the desired signal unless the QRM moves in on top of the
working spectrum. I agree that 40M is a bitch. I have my doubts if
ANYTHING can save that band!

*** There is a reply:   72042

*** More ***

#: 72042 S17/TAPR NNC/DSP
    16-Mar-88  01:51:44
Sb: #72024-HF Modem DSP
Fm: Bob McGwier N4HY 74615,1366
To: Tom Clark W3IWI 71260,3640

Forty does indeed suck.  I can't imagine an adaptive equalizer that I could
run on anything less than the TMS320C30 (40 ns clock) as the ONLY code
running that would come close to adapting fast enough.  FERRRRRGET IT
Bob


*** More ***

#: 72023 S17/TAPR NNC/DSP
    15-Mar-88  23:35:02
Sb: #71974-HF Modem DSP
Fm: Tom Clark W3IWI 71260,3640
To: Barry McLarnon VE3JF 71470,3651 (X)

On the FFT comments, I was only apologizing for a factor of 2, not
a factor of 4! If I said it wrong, flog me with a limp baud. Anyway,
the 'best' spacing should be such that a channel is at the sin(x)/x
zero for the adjacent channel. So what I was trying (very trying!)
to say was 20 Hz for 20 baud or 40 Hz for 40 baud.
.
I told you that I'm not a communications engineer, so you'll have
to bear with me while I muster the correct terminology. My earlier
suggestions was in fact multi-tone coding, one tone per bit. I guess
my use of "m-ary" for that case was imprecise, for which I again deserve
a flogging.
.
Your suggestion of DTMF (or perhaps by extension 3TMF to cram a bit
more in) is intriguing. Guess I should do a few simulations to see
where it leads since obvioulsy it helps the PAR problem a big bunch.


#: 72013 S17/TAPR NNC/DSP
    15-Mar-88  22:01:09
Sb: #71989-#z80
Fm: Lyle Johnson, WA7GXD 76246,565
To: skip wb6ymh 72345,1725 (X)

Sounds good to me, Skip!

Actually, not being able to use existing TNC 2 applications may not be all bad,
since the source isn't available, and the architecture of that box (not
programmable timers, not enough bit-type I/O, can't use auto-enables on the
SIO, etc.) is pretty limited (which makes the magic it performs all the more
mind-blowing!).

Whatcha think of the V40 idea?

Lyle

*** There is a reply:   72053

*** More ***

#: 72053 S17/TAPR NNC/DSP
    16-Mar-88  08:00:30
Sb: #72013-z80
Fm: Jon Bloom, KE3Z 71350,1100
To: Lyle Johnson, WA7GXD 76246,565 (X)

I have a working AX.25 V2.0 implementation in C (I wrote it for Phils's NET
software, although he chose to replace it with his own stuff)... I'll be glad
to recode it in the assembly language of your choice (well, Z80, 8086 or
sub/supersets thereof) if it will help to make the on-board microprocessor
happen for the DSP box.



*** More ***

#: 72041 S17/TAPR NNC/DSP
    16-Mar-88  01:51:38
Sb: #71989-z80
Fm: Bob McGwier N4HY 74615,1366
To: skip wb6ymh 72345,1725 (X)

No I don't see a conspiracy and I confess that a weekend with Riportella and
Art Feller (AMSAT treasurer) is enough to try even Job to the limits of
endurance.  I read and hit the roof after midnight Monday morning 30
minutes after ending the trip back from Washington.  I knew better and
should have just gone to bed and thought it over.  I agree with you on the
80XXX family and since Lyle is already working on the V40 family for another
computer how about killing to birds with one stone.  I know that you are
capable of writing code for it, I didn't know what your personal
capabilities were with the Z80.  This thing is going to be the best thing
since Apple butter.  Phil claims that there are three phases to any project
(1) blind enthusiasm (2) bitter frustration (3) comprimise.  Tom and I have
been doing this for a year and after code began to flow that did things the
blind enthusiasm followed.  I still am in stage one and don't intend to fall
into stage 2.
Bob



#: 72014 S17/TAPR NNC/DSP
    15-Mar-88  22:16:20
Sb: Whither the Z80 Part 1
Fm: Tom Clark W3IWI 71260,3640
To: all

Lyle suggested the need for a list of DSP applications that the
new box could do and a comparison of capabilities with & without
the Z80:
- 9600 Baud modem: Realize that no modem will make silk from a
sow's ear! To run at 9600 will still require a special receiver.
I assume that the special receiver will have a DC-coupled
discriminator output. On the demod side, the DSP box would then
filter the discriminator output, clip the resultant signal and
produce a 1/0 output string. Similarly I assume that the xmtr will
have a direct FSK input. The DSP box would apply pre-filtering to
the data and output an analog signal to the xmtr's FSK input. The
other function which is needed to implement the K9NG standard is
the scrambler. It looks to me like the 3201x can handle the 9600 baud
filtering but may not have enough gas to also do the scrambler on
a full-duplex link. The Z80 would add the requisite horsepower.
- 1200 Baud PSK (i.e. FO-12 and the new PACSAT): The current
software shows that 1200 baud PSK demod plus a 1200 baud FSK remod
runs with plenty of margin. There should be no problem in adding
the 1200 baud PSK or Manchester FSK modulators. The present interface
uses a BELL 202 remod, so the clock recovery burden is placed on
the TNC but this should be do-able in the 320.
- 400/2400 Baud PSK (i.e. RUDAK): RUDAK presents an interesting
problem for the 'stock' TNC in several ways -- the 400 baud rate is
a non-standard speed, and the downlink modulation is Manchester PSK
(400 Baud data xor'ed with a 400 Hz clock). The uplink baud rate is
not available on a stock TNC2 and is not the same rate as the
downlink. Our present 1200 Baud PSK hardware modem is going to need
an adapter widget to work with RUDAK. Given the properties of the
8530 SIO if the Z80 is included, these should be fairly easy to
accommodate, but if the Z80 is omitted the adapter will be fairly
complex.        (continued in part 2)


#: 72016 S17/TAPR NNC/DSP
    15-Mar-88  22:17:54
Sb: Whither the Z80 Part 2
Fm: Tom Clark W3IWI 71260,3640
To: all

- 300/1200 Baud AFSK: A BELL 202 demod has been written and works.
It can copy better than the standard MF10/XR2211 does. There is no
reason this code wouldn't also operate with BELL 103 standards to
support compatibility with current standards. This application could
be included whether or not the Z80 is included. The 103 option
allows the DSP box to fully emulate an AEA PM-1.
- WEFAX: N4HY has shown that a really nice WEFAX demod can be built
in software. The WEFAX software requires some sort of host computer
to format the data for a printer or CRT. This option makes sense
only if the Z80 is included since some data collection/formatting
is required before it can be displayed. With the Z80, a machine as
trivial as a C-64 could conceivably used for display. However this
does require that the TMS3201x and the Z80 have a full 8-bit data
path between the 'engines'.
- FFT Spectrum Analyzers: I have found that an FFT spectrum
analyzer is one of the most useful pieces of test equipment I have
available. The WEFAX comments are echoed for this application also.
- HF modems: My proposal for m-ary OOK (on/off keying) with m=16 or
m=32 tones should be do-able with either option. After thinking about
the HF problem even more, I have become convinced that the addition
of some amount of FEC (at Tucson I suggested 10 bits to correct 32)
will add tremendously to the link reliability. I also made the
(perhaps heretical) suggestion that HF links could be helped by the
addition of some backoff strategy on PACLEN and even further by the
inclusion of a datagram-oriented strategy. It is my considered
judgment that any (or all) of these reliability enhancements cannot
be done with a 'nude' TMS3201x and that the Z80 is needed.
In short -- a 'plain-Jane' TMS3201x will give us a few nifty
things, but the Z80 increases the flexibility remarkably. Bob and
I have discussed it at length, and from where we sit, there is only
one obvious choice.
73, Tom


#: 72018 S17/TAPR NNC/DSP
    15-Mar-88  22:29:58
Sb: #71937-dsp 1 4 fo 4
Fm: Tom Clark W3IWI 71260,3640
To: Lyle Johnson, WA7GXD 76246,565 (X)

Lyle, I have posted a companion pair of msgs outlining the applications
that are either ready today or which are on the drawing boards. I
don't claim that the list is complete, but it is a pretty fair sample.
.
I disagree with your market forecasts. Assuming that it works, I
would bet that the total market level is closer to that of the TNC2
(and all its clones)! If we do this right, it ain't just a whiz-bang
modem -- it's a nearly universal accessory. Every time Bob and I
put on one of our Travelling DSP Circuses and ask who wants one,
the audience response exceeds 80%.


#: 72052 S17/TAPR NNC/DSP
    16-Mar-88  08:00:23
Sb: #71950-dsp 1 4 fo 4
Fm: Jon Bloom, KE3Z 71350,1100
To: Bob McGwier N4HY 74615,1366

I duuno the numbers, Bob, but from where I sit the HF FAX stuff is one of the
growth modes.  In the past year or so, we have gotten a surge of phone calls
and letters on this subject, and the WEFAX articles we've published have gotten
a better response than just about anything else.  All of which leads me to
believe that there is a nearly untapped market out there for low-cost video.
SSTV has always been burdened by a high cost problem (priced a Robot 1200
lately?)  But I suspect that a relatively low cost box that does SSTV, as well
as FAX and the digital modes, would get a good response.  People want new and
interesting things at low cost.  (Well, naturally!)  If it just plugs into the
radio and/or computer, costs no more than a couple of hundred bucks, and does
something "neat," it'll find a big market.  In my opinion.

BTW, things are getting to a fine state when you start arguing with yourself --
and losing!



*** More ***

#: 72025 S17/TAPR NNC/DSP
    15-Mar-88  23:35:37
Sb: #71975-#RE: HF Modem DSP #2
Fm: Tom Clark W3IWI 71260,3640
To: Barry McLarnon VE3JF 71470,3651 (X)

Of course I read them! That's part of what started me thinking
heretical thoughts!
.
Re HDLC -- certainly there is no real magical, mystical requirement.
If the Z80 is included in the DSP box then the DSP hardware can work
on analog signals and leave the Z80 to to bit-diddling.
.
Now, good buddy, when are you going to transform your ideas into
some 320 code we can use? The way to get your ideas into the world
is thru the Golden Rule (usually stated "He with the Gold Rules",
but in this case its "He with the Code Rules").
73, Tom

*** There is a reply:   72044

*** More ***

#: 72044 S17/TAPR NNC/DSP
    16-Mar-88  01:52:07
Sb: #72025-RE: HF Modem DSP #2
Fm: Bob McGwier N4HY 74615,1366
To: Tom Clark W3IWI 71260,3640

I really like the ideas here.  I predict that so long as the user interface
functionality does not look remarkably different to that of TNC-2 we could say
it was Gobble dee Gook.25 version 19.1 protocol and they wouldn't care if
the bits got through the muck.  Lyle does indeed have a point about the AGC
and whatever EQ we have done in the past goes out the door.  The amplitudes
have all changed etc.  Not everyone owns (or wants) a TS-940 and has the
very capable PBT.  I am not sure about the "most".  I think Barry has a good
idea about starting with a protocol that doesn't need my fast adaptive HF
equalizers to work.  We don't have enough data space or ticks per sample to
be able to implement this.  I will check into seeing what subset of the
adaptive schema we could use.  Barry suggests that a "flag" should be sent
that aids in rapid clock recovery.   We could also use it to update the
coefficients in the adaptive filter at the beginning of each frame or
subpacket by retaining the old coefficients when "no proper signal" is
being detected.  The problem with using the blind adaption schemes that are
popular elsewhere is that make use of the bauded nature of a "standard"
signal which has some Kurtosis associated with it as in the Godard EQ.
We can make 20m a lot better, 40 work as well as can be expected and 80 is
up for grabs in my book.  The crudest EQ we can get away with is amplitude
response flattening with a long term averaged spectra.  That ain't fast
enough.  We put in a "guess" as to the shape of the amplitude spectra and
then adapt.  I think this pure power spectrum flattening will work in
reasonble conditions.  I say let's get down to it.
Bob

#: 72033 S17/TAPR NNC/DSP
    16-Mar-88  00:24:37
Sb: DSP-1
Fm: Bob McGwier N4HY 74615,1366
To: ALL

On Lyle's design:
(1) DSP CPU:  I think the 12.50 extra spent on 25 Mhz is worth it
(2) Program memory:  On the FFT stuff we have already working, we use more
than 2K for the 1024 point FFT (real and complex 16 bits each that's 4096 K
right there) we need the "all but 512" option.  I like the logic concerning
both medium charges, which will not be popular, and the vigilance against
that will unnecessarily increase the trouble to keep leakage down like
external RAM.
(3) I like everything here and I hope we can stay away from 8254's.
(4) Analog I/O: I don't think we can use 200 Khz but since it is so cheap
 I am glad to have the ability to run higher sample rates.  I am with you on
the 8 bit A/D unless someone comes up with a set of supportable claims of
why we will shoot ourselves in the foot with 8 bit A/D.  A case in point:
I think I have told most of you about the Soviet probe that was sent to
Halley's comet, just in case I haven't ;-) . .   The Soviet and French
built the VEGA   (Venus Earth    "Galley"  Russian for Halley) probe.  On
the way to Halley they dropped two balloons into the atmosphere of Venus.
Neither the Soviets or JPL or the French could demodulate some of the most
important tranmissions because of the depth to which the balloon sank.
After they gave up, they asked if I would look at it.  I was able to
demodulate the signals and after the Viterbi decoder, there were no bit
errors.  This was one bad MF signal lots of noise and doppler.  It was 8 bit
A/D and the internal processing was done after converting to 16 bit but the
dynamic range had been determined by then.  8 bits is enough if we are
careful in our use of it and don't fill it up full of computer hash through
some ground loop.  (Continued)



#: 72034 S17/TAPR NNC/DSP
    16-Mar-88  00:24:51
Sb: DSP-1   II
Fm: Bob McGwier N4HY 74615,1366
To: ALL

I can't believe that we used to pay BIG bucks for 8 bit that would run that
fast.
Also, good perception that 31.5 uSec conversion time for the 12 bit is not
enough to do MartinSat.  I will pitch the 8 bit with you.
5) Filters.  I noticed on your block diagram that you put the filters in the
cartridge and that does make it the most versatile.  If that turns out to be
a pain in the butt or very expensive, then drop it and go with the fixed
anti-aliasing filters.  It should be clear that Hi-FI and FO-12 PSK need
different filters for optimal performance.  If this could be put into the
cartridge that would be great.  If we can program the MF-4 and accomplish
the same task that is fine with me.  I do see the need for different filters
especially on the D/A side so as to have clean signal going into
transmitters in those cases where we use the audio line for modulated bits.
6)
As I am sure you know by now I want the general purpose microprocessor,
whatever form that takes.  I want this box to be able to totally stand alone
and talk to an RS-232 to send data.  This gets us the ability to talk to
everyone from commode door 64 to the toaster ovens that make pictures.  I
see that you already thought about the host I/O to do more than serial bits.
This is slower than shared memory but a very reasonable comprimise and I am
sure a great deal cheaper in terms of parts and hassle.  I like everything
here but the RAM limitation but I have already said that.  I am sure that a
bank switched EPROM will make it easier to switch modes.  For only $6.00
that is an awful lot of added functionality.
7)  Given that your suggestions in 6 are followed I agree the Bel202 is
superflous for everyone including PK-64 owners since this will replace their
unit.
(continued)



#: 72035 S17/TAPR NNC/DSP
    16-Mar-88  00:25:05
Sb: #DSP-1  III
Fm: Bob McGwier N4HY 74615,1366
To: ALL

8) Non-silicon:  DAMN I wish this were ONLY software.
Surely the box for the GLB PK-1 is cheap.  Is that the one you are talking
about?  I wonder if we look that cheap if it will hurt us more than saving
ten bucks?  The shielding is very important.  With the Delanco Spry boards
and 12 bit A/D we are still seeing the effects of noise.  The EME
experiments Tom and I were doing are computer dependent.  When he was still
grounding the case of his PC to the BNC's on the Delanco Spry, he was having
trouble and this drove him to the drastic shaving of the collar on the BNC's
that connect to the board.  We need the tempest mentality for this widget.
I agree that we should bypass the Z80 with a modem disconnect if a person so
desires.
9)  Give us more detail on the "development costs".  Artwork? layout?  If I
knew what this entailed I might be able to find someone smart to figure out
a way around it or better yet, someone smart will make it so I don't have to
bother.  Maybe in describing it, you will have a brainstorm. ;-)
Unfortunately, I believe that paranoia PALS will be popular with OEM'ers.
I am hot to trot for Dayton also, sure would like Lyle to be able to show
this thing off.
Bob


*** There is a reply:   72066

*** More ***

#: 72066 S17/TAPR NNC/DSP
    16-Mar-88  11:32:55
Sb: #72035-DSP-1  III
Fm: Harold Price, NK6K 71635,1174
To: Bob McGwier N4HY 74615,1366

I sure which we'd get a desire to show off at dayton of the lists of
requirements for DSP boxes.  That's one of the several things that got us in
trouble at Dayton.  Unless you have a pile to sell there, there is no need to
hold up a circuit board.  Holding up the delanco board is sufficient,
especially if the reaod-show is demoed. Lets proceed with all due hast, but not
for the sole reason of showing off at Dayton. hp


#: 72037 S9/Packet Radio
    16-Mar-88  00:42:25
Sb: #71953-NET/ROM and KA9Q TCP/IP
Fm: Bob McGwier N4HY 74615,1366
To: Franklin Antonio, N6NKF 76337,1365

Correct.  Sorry if I didn't make that clear.  The stuff for Phil's code
allows IP fellows to USE a NET/ROM network AND allows any other NET/ROM node
to use it as an intermediate node in a chosen route.  It does not have the
user end node code.
Bob



#: 72038 S17/TAPR NNC/DSP
    16-Mar-88  00:42:33
Sb: #71963-#TMS320C1X part II
Fm: Bob McGwier N4HY 74615,1366
To: David Toth VE3GYQ 72255,152

I hope you and he are right cause I couldn't be pushing harder for us to be
able to do what that box does since we are associated so closely with
packet, we will have a hard time pushing this I believe until we add that
functionality simply because of the cost.  I agree with Lyle's analysis that
we need to do these functions to make the box worth the current projected
price or a person will be able to say (justifiably) for a few dollars more I
can get . . .  I don't believe that promised software from us is our long
suit with Joe and Mary HT.  I want it before the kits are ready.
Bob


*** There is a reply:   72065

*** More ***

#: 72065 S17/TAPR NNC/DSP
    16-Mar-88  11:32:44
Sb: #72038-TMS320C1X part II
Fm: Harold Price, NK6K 71635,1174
To: Bob McGwier N4HY 74615,1366

Sigh.  The point is 1)  Will Joe Ham pay more for a box that does just a little
more than the big manufacturers box does?  If we sell this thing as an 8 or 9
mode TNC, the fact its a DSP box gets lost.  Also, if we sell it as a TNC,
we're competing against the manufacturers again, something I though we decided
we didn't want to do.  For one reason, if there is not enough differenition
between this box and a box in their current product line, they won't want to
license it.  We don't get royalities, and the who game stops. That's why it
still like to see a cheap add on box that is clearly a modem, something you
should get even if you already have a tnc.  The way the DSP-1 is being
packaged, you've got to ask your self if you want to replace your existing $300
tnc.  I think that most of our weak sig or satellite user base will already
have a TNC.  Adding the hardware needed to make a modem into a TNC may look
cheap, but I thinks its a bad marketing decision, and bad for Joe and Mary in
the long run, i.e., it raises the minimum cost of participation.  I'd like to
play with fancy data compression techniques in the co-processor too, including
some sort of universal pixel-graphic interface so you can get wefax at the cost
of writing a 10-line basic program for your computer and sending h*v*colors to
our box. That's what the big one is for.  Here's the minority opinion (and
maybe its down to a minority of 1); DSP-1 (first box), just-a-modem that does
fo-12/uo-C/u-sat, maybe an improved HF protocol, and some wefax/fax stuff that
requires programming on the host computer for < $175.  DSP-2, the big high end
bit-whackers box, does all, costs lots.  No intent for Joe & Mary to own one.
3) DSP-3, the outcome of the experiments in DSP-2, a Joe and Mary does all in
the $300-400 range.   DSP-1 is done now, DSP-2 is done overlapping, DSP-3 is
done next year.

#: 72045 S17/TAPR NNC/DSP
    16-Mar-88  02:10:48
Sb: V40 vrs Z80
Fm: skip wb6ymh 72345,1725
To: dsp'ers

Lyle: Let's not forget that Phil already has a complete AX25 level 2 in his TCP
package these days written for the PC.  Doesn't sound like the actual protocol
code would be much of a problem.  The user interface is all that would need to
be written/modified.

Z80/V40: Well Tom's convinced me, I have always wished I had a spectrum
analyzer and it's clear the DSP 2001 can't be one without a GP processor.

I had no idea the V40 would only be $10 more than the Z80! The V40 also has an
8085 emulation mode, existing TNC2 code may be converted to run on the V40 by
recoding the Z80 specific instructions.  If the program doesn't make extensive
use of IX or IY or the primed register set this would actually be fairly easy
to do (easier than recoding into 8086 assembler anyway).

The V40 also solves the sample clock generation problem one of the three on
chip timers will easily fill that requirement.

With a V40 and 8530 we have 3 serial port, 2 HDLC capable, anyone have a hot
idea for use of the "free" serial port on the V40?

#: 72049 S9/Packet Radio
    16-Mar-88  03:31:50
Sb: #72047-HF digipeaters?
Fm: Phil Karn, KA9Q 73210,1526
To: Phil Karn, KA9Q 73210,1526

Tom,

Perhaps the solution to the Peak/Average power ratio problem is the following:

Let's say that you have N frequency "slots" in your passband.  During
any given symbol interval, a slot either has or doesn't have energy in
it.  You therefore have a signal set of 2^N possible symbols.

Out of this set, select a "valid subset" containing only those code
words that have roughly constant numbers of zeros (no energy in slot)
and ones (energy in slot).  Voila, constant transmitter output power.
Naturally, you pick the valid symbols to have maximum Hamming distance
from each other.  This gives you a simple form of block coded forward
error correction "for free"; all you need is a lookup table to convert
the received symbols back into information bits

You could even have a family of codes of different sizes (and Hamming
distances) to give you a "knob" to turn for extra coding gain when
things get rough.  It should be easy to write a small computer program
to find signalling sets for an arbitrary value of N.

Phil

#: 72098 S17/TAPR NNC/DSP
    16-Mar-88  23:18:34
Sb: #Challange
Fm: Harold Price, NK6K 71635,1174
To: DSPers

In Star Trek 4, during the scene where Uhura and Chekov are asking Scotty to
beam them up from the reactor room, there are AX.25 HF packets in the sound
effects.  Your task: Decode them. HP.

*** There is a reply:   72108

*** More ***

#: 72108 S17/TAPR NNC/DSP
    17-Mar-88  00:40:33
Sb: #72098-Challange
Fm: Bob McGwier N4HY 74615,1366
To: Harold Price, NK6K 71635,1174

Are  you serious?  I will go rent the tape again for the third time
tommorrow.  This is when they are on board the USS Enterprise aircraft
carrier?
Bob

#: 72101 S17/TAPR NNC/DSP
    17-Mar-88  00:19:55
Sb: #72065-TMS320C1X part II
Fm: Bob McGwier N4HY 74615,1366
To: Harold Price, NK6K 71635,1174

Oh well.  I guess we won't all agree on this one.  The next one we are
capable of doing will be just unbelievable in terms of its potential.  On
this one, I really want this to be self contained and the way to do it is to
put a GP microprocessor in it.  Yes I really want to be part of a TNC-3
effort there is no doubt of that.  Also, I don't want it limited to UOSAT-C,
FO-12, PACSAT, AO-13, or even HF packet with an uninteresting scheme.  This
thing will turn HF signalling on its ear with a little work.
On another topic approriate for this section:
I have read through the Quadron manual and it looks like you and your
partners have been really busy, that is a lot of work.  I hope that the
needs of the PS-186, V40 CPU, and 8018X that is on MartinSat can be
addressed soon.  Looks like you have a really nice kernal and we need it.  I
doubt we need all the bells and whistles that are there but you knew that
already.  Pipes and multitasking and the DMA drivers you have done and are
doing will make the job easier.  How do we proceed from here?  Does TAPR
need to work out some kind of nondisclosure arrangement or license or
whatever with yur company so that we can get this for the CPU work?

Bob

#: 72127 S17/TAPR NNC/DSP
    17-Mar-88  11:05:22
Sb: #72011-TAPR DSP 1
Fm: Barry McLarnon VE3JF 71470,3651
To: Lyle Johnson, WA7GXD 76246,565

That's the cleanest way of doing it.  For some low sample-rate applications
though (like sampling the outputs of ssb radios), it would suffice to have a
single a/d converter with an analog multiplexer ahead of the sample & hold.


#: 72128 S17/TAPR NNC/DSP
    17-Mar-88  11:05:51
Sb: #72012-HF Modem DSP
Fm: Barry McLarnon VE3JF 71470,3651
To: Lyle Johnson, WA7GXD 76246,565

That's a point that concerns me too, although most recent-vintage receivers
have IF shift, width, etc. controls that allow the bandwidth to be optimized to
some extent.  I think we'll end up with at least one format designed to make
the most of the bandwidth provided by typical SSB filters.  600 Hz is kinda
cramped to do much interesting with though.

I think that the answer to the 40 meter problem is at hand... it's called 30
meters!

*** More ***

#: 72130 S17/TAPR NNC/DSP
    17-Mar-88  11:07:26
Sb: #72023-HF Modem DSP
Fm: Barry McLarnon VE3JF 71470,3651
To: Tom Clark W3IWI 71260,3640

Instead of nTMF, let's call it n-out-of-m signalling (set of m possible tone
frequencies, n transmitted at a time).  I've generated a little table to aid
in the analysis.  Baud rate is assumed to be 50 bd.

                  m = 16                             m = 32
               ------------                       ------------
 n     Combinations   Equiv. bit rate     Combinations   Equiv. bit rate
---    ------------   ---------------     ------------   ---------------
 1          16              200                32              250
 2         120              345               496              448
 3         560              456              4960              614
 4        1820              541             35960              757

So for m = 16, two tones could be used to get to 300 bps, and for m = 32,
three tones would get us to 600 bps.


#: 72129 S17/TAPR NNC/DSP
    17-Mar-88  11:06:48
Sb: #72025-RE: HF Modem DSP #2
Fm: Barry McLarnon VE3JF 71470,3651
To: Tom Clark W3IWI 71260,3640

I was afraid you'd ask that... it's so much easier to talk about this stuff
than to actually do it! :-)

As I mentioned before, I HAVE implemented a more-or-less conventional 300 baud
modem, the intention being not so much to improve on existing modems, but to
provide a new front end for them which has intelligent diversity combining of
the outputs of two receivers (i.e., two good 300 bd demods, smart combiner,
clock recovery, and a re-modulator).  I'm still convinced that, no matter what
exotic new modems and protocols we come up with, space/polarization diversity
reception needs to be in our arsenal.  The great thing about it is that, except
for the extra antenna and receiver needed, there's no cost in terms of added
bandwidth, transmitter power, etc... we're just capturing more of what's out
there in the ether and using it intelligently.  I want to see what it can do
for the present HF packet links, as a baseline for future endeavours.  What I'm
doing right now is putting a little piggyback board on the D-S board to add a
second analog input.  My main concern at the moment is how to provide tuning
indicators for the two radios.

I'll try and clean this up asap and get on with something else.  Although I
don't expect a concensus from all concerned on what that something else is
before I start coding, it would be nice to at least have a few murmurs of
approval so I know I'm not wasting my time.  As the discussion of the last
couple of days clearly shows, there are still many issues to be discussed, and
I don't purport to have all the answers.

 Cheers, Barry

#: 72157 S17/TAPR NNC/DSP
    17-Mar-88  21:04:37
Sb: #72108-#Challange
Fm: Harold Price, NK6K 71635,1174
To: Bob McGwier N4HY 74615,1366 (X)

Yes.  It sounds like they took a section of 20 meters to use as "interference".
To make the challange a little harder, the packets aren't on frequency.  I
thought I heard packets when I saw St4 opening night, when I bought the tape
the day it came out I was sure.  I told Jon Bloom about it the next day, and I
think I mentioned it to Phil a little after that. hp

*** There is a reply:   72181

*** More ***

#: 72181 S17/TAPR NNC/DSP
    17-Mar-88  23:21:01
Sb: #72157-Challange
Fm: Bob McGwier N4HY 74615,1366
To: Harold Price, NK6K 71635,1174

That is hilarious.  Off frequency is no problem so long as both halves of
the spectrum are there (above and below center frequency +/-  0.5*shift).
If not we could try a mark only or space only demod depending on which was
left alone.  It is a 3 dB penalty but it might be doable.
Bob

#: 72182 S17/TAPR NNC/DSP
    17-Mar-88  23:21:27
Sb: #72130-HF Modem DSP
Fm: Bob McGwier N4HY 74615,1366
To: Barry McLarnon VE3JF 71470,3651 (X)

I like it and we get consistent envelopes and not those that occasionally
add up (all tones nearly equal in phase and near a max) and the xmtr clips
the thing all over the band.  m choose n signalling, surely that has some
kinda name from someplace.
Bob



#: 72183 S17/TAPR NNC/DSP
    17-Mar-88  23:21:40
Sb: #72129-RE: HF Modem DSP #2
Fm: Bob McGwier N4HY 74615,1366
To: Barry McLarnon VE3JF 71470,3651 (X)

I really like the m choose n scheme.  That is codable and at 50 baud should
strain the communications link between D-S and the PC.  A straight table
lookup on the PC and then to display.  The only real problem I see to be
licked is clock recovery and if we follow Clark's suggestion about a tone
going on off on off on off at one end and have a tone always on at the other
we get clock with work.  Clock can probably be recovered with a early late
gate approach where we find a beginning sampling point that minimizes the
tone every other period and then we will be strictly in the baud that has
the tone off.  What we do to maintain a lock on this on off tone timing is
going to be the most difficult part of the whole algorithm, given that we do
nothing about tuning as yet.   This is a short and sweet FFT, sine table is
pretty small.
Bob



#: 72189 S17/TAPR NNC/DSP
    18-Mar-88  00:01:49
Sb: #72044-RE: HF Modem DSP #2
Fm: Tom Clark W3IWI 71260,3640
To: Bob McGwier N4HY 74615,1366

The 80m problem is not as serious as you might believe. 80's big
problem is that most signals of interest come in at high incidence
angles, and hence there is a lot of multipath. RTTY/AMTOR experience
is that 80 is pretty reliable at lower baud rates -- hence my original
suggestion to pick some scheme 50 baud or slower, i.e. at least
20 msec for each decision. You may throw away the first 10 msec of
each aperture window, but you'll have enough left to make a decision.
80M does not have the horrendous QRM problems of 40 (most of the
time). 80 also has a rather high background noise level with lots
of non-Gaussian (impulsive) crud.
On radios, all the more modern radios (TS440, TS940, FT980, IC745,
IC761 etc) have pretty much the same type of filter schemes. I doubt
than any DSP box would allow an old HRO or SX-71 to do much on HF.
The newer radios I cited all have fully synthesized LOs with frequency
stabilities of 20 Hz or better. The older analog LO radios (75S3, TR-7,
TS820 etc) probably will never cut the mustard. Fortunately, even
with the declining dollar, the TS440/FT757/IC751 class radios are
still under $1k. So a TS940 is not (and should not) be a requirement
(but I sure do like mine!).
Barry's protocol suggestions are great. I'm glad to see that we now
seem to have a significant discussion going on now. The FOM (few
of many) tone schemes look like a very interesting compromise.

*** More ***

#: 72191 S9/Packet Radio
    18-Mar-88  00:02:37
Sb: #72049-HF digipeaters?
Fm: Tom Clark W3IWI 71260,3640
To: Phil Karn, KA9Q 73210,1526 (X)

But Phil -- the Peak-to-Average problem is due to the fact that each
of the n tones is coherent, so that the peak voltage the radio is
required to handle is the sum of the individual amplitudes.
We don't have the situation of the orchestra with n musicians each
producing p watts (for which we would need n*p watts in the amplifier).
In a multi-tone signalling case we have the bizzare example of n
musicians, each coherently locked to some common frequency reference,
so our power requirement becomes more like n^2*p since there will
be times when all the vectors do line up .... OUCH!
I come from a world where my signals are noise and I naively assumed
that the tone power adds in my initial thinking. WB2TNL in a comment
over a beer last week really opened my eyes on this one! The peak-to-
average ratio required seems to me to be of order n^2:1 for n tones.
My n=32 OOK example, even if only half the tones are statistically
on given well distributed data then requires PAR's in the 20-30 dB
range. You gotta run a KW in order to have a few watts of average
power, which ain't a very efficient trade-off.
Barry's suggestions on a 'few-of-many' sequence (DTMF being a trivial
example) seem to offer a compromise to keep PAR below about 10 dB
(i.e. n=3 or 4) and still pack data more efficiently. The best schema
would be one which is constant envelope, but that may be asking too
much.
73, Tom


#: 72229 S9/Packet Radio
    18-Mar-88  16:59:33
Sb: #72191-HF digipeaters?
Fm: Barry McLarnon VE3JF 71470,3651
To: Tom Clark W3IWI 71260,3640

Tom, things aren't quite as bad as they seem, and we should not abandon all
hope of using multitone modems.  Here's why:

Your estimate of the PAR is a little on the high side.  When N equal-amplitude
sinusoids are added together, the PAR of the resulting signal is nominally
equal to 20*log[SQRT(2N)].  For N = 16, this works out to about 15 dB, and for
N = 32, it is about 18 dB (I am ignoring for the moment, the varying number of
simultaneous tones if OOK is used).

Also: up to a point, you can clip the peaks of the waveform (before applying it
to the SSB modulator) without doing any harm.  The limit is reached when the
"self-noise" from intermod products start to have a significant effect on the
bit error rates.  Commercial 16-tone modem systems are typically run at 3 to 5
dB higher average power than that dictated by the PAR.

Here's an interesting footnote:  The reason I referred to the PAR above as
nominal is that it can be reduced if we put some constraints on the sinusoids.
The first constraint is that the tone frequencies be equally spaced, which we
want anyway.  Now if we control the phases of the tones (easy with DSP!), we
can reduce the PAR quite dramatically. The absolute worst choice is to start
them all in phase - then we get no improvement at all.  However, with the
proper choice of just two different phases, 0 and pi, for each tone, the PAR
can be made MUCH lower.  For N = 32, the PAR can be reduced to 6 dB.  And there
is an even better algorithm that requires a different phase shift for each tone
(which can be stored in a look-up table). It results in a PAR of 4.6 dB (!) for
N = 32, and the PAR is <6 dB for ALL N. For large N, it produces a
near-constant-envelope signal that bears a striking resemblance to a swept
tone.  The bad news is, if we start phase- or amplitude modulating the tones,
we upset the applecart and the PAR starts heading back up.  Everything is fine
as long as we don't try and transmit any information! :-)

73, Barry

#: 72193 S17/TAPR NNC/DSP
    18-Mar-88  00:14:11
Sb: DSP 2001
Fm: Lyle Johnson, WA7GXD 76246,565
To: DSPers

Barry, Jon, others,

Just to bring you up to date on the latest thinking...

Metal box with general purpose cpu (GP-CPU) = NEC V40 with four 32-pin JEDEC
bytewide sites for up to 1/2 meg or memory.  bbRAM.  V40 has 8530 that is DMAed
for how-fast-you-want data.  DSP modules plug into gp-cpu, and it has "slots"
for two of them.  320C10/15 now, DSP56001 next year, who knows after that?

Kit price with a 32K eprom and a 32k bbRAM and a TMS320C15 DSP w/8-bit analog
port expected in the $250 bracket (like a TNC 1 without a cabinet).

Box would be mostly CMOS and run on 12 vdc.

There would be a full 16-bit input and output port availabe on the DSP cards,
and there would be an 8-bit "host" port to/from the gp-cpu for higher-speed
transfers.

For the 320C1x DSP module, the gp-cpu can grab the BIO, INT, RESET, and
addr/data busses (but only by halting the processor).  The 320C1x can each hit
a pair of INT lines to the V40 as well (so we can handshake data fast between
the processor if need be).  Obviously, the box will have limitations, but it
should be roughly an order of magnitude higher performance than anything we
have now as Amateurs.  Should be able to do cheap digital video (FAX/SSTV class
stuff) plus all the HF experimenting you want, etc.  4-layer PC boards of
course.

What do you think?

Lyle

#: 72217 S17/TAPR NNC/DSP
    18-Mar-88  10:28:44
Sb: Tape recorder advice?
Fm: Barry McLarnon VE3JF 71470,3651
To: All

It pains me to have to do it (I'd MUCH rather spend the money on computer and
radio toys), but I'm going to have to bite the bullet and buy a good-quality
cassette recorder to support future DSP endeavours.  Anybody got any
recommendations?  Is Nakamichi still in a class by itself, or are there some
less expensive alternatives?

Barry

#: 72238 S17/TAPR NNC/DSP
    18-Mar-88  21:32:01
Sb: #320C15 chip
Fm: Lyle Johnson, WA7GXD 76246,565
To: DSPers

I checked with TI today regarding the TMS320C15 chip.

The word I got is that the chip is available in pre-poduction samples only,
called the TMP320C15, in the $40-$50 range.  They couldn't say if this was for
a 25 MHz part, or only a 20 MHz part.  I should know that next week.  When the
part is fully qualified, it will change from the TMP prefix to the TMS prefix.
It is slated for production quantity availability in the 3rd quarter, and will
sell in the low $20s in 1000 quantities.

The internal EPROM version, TMS320E15, is fully qualified and sells for $65 in
100s, $55 in 1000s.

What all this means is that the cost to produce this thing should be about $15
less than I guessed - providing some slack to cover the things I overlooked!

Lyle

*** There are replies:  72247, 72285

*** More ***

#: 72247 S17/TAPR NNC/DSP
    18-Mar-88  23:15:26
Sb: #72238-320C15 chip
Fm: Bob McGwier N4HY 74615,1366
To: Lyle Johnson, WA7GXD 76246,565 (X)

That kind of news you can keep coming.  To bad it is not TMS right now!
Bob


*** More ***

#: 72285 S17/TAPR NNC/DSP
    19-Mar-88  13:32:12
Sb: #72238-320C15 chip
Fm: Bob McGwier N4HY 74615,1366
To: Lyle Johnson, WA7GXD 76246,565 (X)

I have thought about this some more.  TI is also pretty bad about announcing
stuff, then waiting to see if a market develops before pursuing it strongly.
They announced the C25 almost two years before anyone got hold of one and
the TMS320C30 was talked about in detail at the ICASSP meeting in Dallas in
'87.  I have tried relentlessly to get one at work and can't.  We bring four
or five of TI Fellows in to work with us each and every summer and they take
back as much as they bring.  If we can't get them I don't know who can.  If
you can't get a sample post haste, then lets put 10's on the damn thing and
offer the 15's as an upgrade.  I will NOT be able to do adaptive EQ without
the extra memory and frankly Adaptive EQ is secondary only to the ability to
switch applications in why DSP is important to bauded signals.
Bob



#: 72239 S17/TAPR NNC/DSP
    18-Mar-88  21:32:57
Sb: #72217-Tape recorder advice?
Fm: Lyle Johnson, WA7GXD 76246,565
To: Barry McLarnon VE3JF 71470,3651 (X)

I have a Sony TC-5DM, a professional quality portable deck. COsts about $900.

Lyle

*** More ***

#: 72284 S17/TAPR NNC/DSP
    19-Mar-88  13:32:00
Sb: #72217-Tape recorder advice?
Fm: Bob McGwier N4HY 74615,1366
To: Barry McLarnon VE3JF 71470,3651 (X)

BANG/BUCK Nakamichi is all by itself.
Bob

#: 72257 S9/Packet Radio
    19-Mar-88  01:32:21
Sb: #72191-HF digipeaters?
Fm: Phil Karn, KA9Q 73210,1526
To: Tom Clark W3IWI 71260,3640 (X)

Tom,

You're right.  I realized after sending my note that you were worried
about the peak/average power ratio on the short term (i.e., within each
symbol) while I was thinking about the change in symbol energy from one
symbol to the next.  I don't think you're going to get constant envelope
output unless you transmit only one tone at a time (remember what a
scope shows for a two-tone SSB transmitter test).

Phil



#: 72258 S17/TAPR NNC/DSP
    19-Mar-88  01:32:41
Sb: #72193-DSP 2001
Fm: Phil Karn, KA9Q 73210,1526
To: Lyle Johnson, WA7GXD 76246,565 (X)

Re DSP architecture --

One minor problem I've run into with the Delanco Spry card is that the
A/D converter doesn't have a constant conversion time.  That means if
you tie the "convert done" line from the A/D converter to the BIO pin of
the DSP chip and then synchronize your D/A output instructions to it,
you can get phase jitter on the analog output signals.  I'm not sure
what the solution is here, but there should at least be a jumper field
to allow the user to strap the card in various ways, e.g., by driving
the BIO pin directly from a programmable timer and making the A/D
Conversion Complete signal available through a regular input port.

I'm all for adding an 808x-family processor to the board (the V-40 is
fine).  There's no reason to use the Z-80 in any new designs.

Phil

#: 72294 S17/TAPR NNC/DSP
    19-Mar-88  16:57:05
Sb: v family microcode
Fm: skip wb6ymh 72345,1725
To:  76246,565 (X)

Lyle:  New microcode for the V family sounds interesting.  I had heard quite a
while ago they were going to add Z80 compatibilty to the alternate instruction
set, but since such a long time had passed without it appearing I chalked it up
to "vaporware".  Did you hear anything about this from NEC? maybe we can have
our cake and eat it too.

#: 72307 S17/TAPR NNC/DSP
    19-Mar-88  19:52:11
Sb: They're Here!
Fm: HamNet SysOp Scott W3VS 76703,407
To: DSP'ers

Gang...

The dreaded PS-186 crew (sounds like a NYC school basketball team!) has been
admitted here.  Franklin and Mike Brock have both been enabled for Section 17
access.

Scott

#: 72336 S17/TAPR NNC/DSP
    20-Mar-88  11:31:55
Sb: TMS320 vs DSP56001
Fm: Bob McGwier N4HY 74615,1366
To: ALL

Holy mackeral!!

1024 point FFT using the most efficient algorithm for these types hardware
(the Danielson-Lanczos done 15 years before the world had heard of Cooley
Tukey FFT) does bit reversal BEFORE it does the inner products. This is much
more efficient since it computes sines and cosines once in the outer loop and
in the inner it uses a recurrence relation for multiple angles to compute
them so no function evaluation is needed there.  I can make this run in
3.39 ms on the DSP56001 and the best I can do on the TMS320C25 is 17 ms.
This is strictly due to greater parallelism on the Motorola but otherwise
the clockrate is the same (10 MIPS).  I believe that all can figure that
is five times "mo bettah".  FIR's and IIR's make even better use of this so my
original estimates for the speedup over the TI chip may have been a gross
underestimate, let me do that again more carefully.  Steve Sagerian told me
he would ship the completed DSP56001 unit back to me next week.  He had
already acquired the remainder of the parts and was almost done.  A modicum
of testing and then back it would come.  3.39 msec, for crying out loud I
have seen implementations on the cray-1 (remember that is 64 bit floating
point versus 24 bit fixed point) that were slower. Of course they weren't
written by me in Crayola - the cray assembler.
Bob

#: 72398 S17/TAPR NNC/DSP
    21-Mar-88  06:47:52
Sb: TNC/DSP fm Italy
Fm: Alberto E. Zagni I2KBD 71360,3467
To: Lyle Johnson, WA7GXD 76246,565

Dear Lyle, if the Italian point of view on TNC/DSP can help a bit, here it is
(I'm with TAPR from the good old days of TNC1s): People are willing to spend
more ($100-150) if they get some more stuff (and never will use it!). The top
selling TNC are PK232 and KAM, even if nobody use AMTOR or FAX or RTTY. Also a
TNC with DSP is much more welcome rather than a simple super "modem". So, my
input is ADD Z80, Wefax and maybe Star Trek decoding (Bob N4HY knows why...)
Best wishes and 73s from Italy, Alberto I2KBD

#: 72408 S17/TAPR NNC/DSP
    21-Mar-88  10:11:09
Sb: #72336-#TMS320 vs DSP56001
Fm: Harold Price, NK6K 71635,1174
To: Bob McGwier N4HY 74615,1366 (X)

Hey Phil, are you going to get us some free samples of the new ATT DSP16A?  The
marketeers say its the fastest single chip DSP on the market.

*** There is a reply:   72442

*** More ***

#: 72442 S17/TAPR NNC/DSP
    21-Mar-88  19:57:06
Sb: #72408-TMS320 vs DSP56001
Fm: Bob McGwier N4HY 74615,1366
To: Harold Price, NK6K 71635,1174 (X)

The DSP32C is faster and I am going to get working on that with NN2Z whose
boss is in charge of that division and pushing him hard to get into DSP.
Might be interesting to have one of their development systems to play with.
The only problem with AT&T is that they like to price their stuff so that
others vendors using their stuff can't compete with their own manufacturing
folks.  Phil is at BELLCORE now and not at Bell Labs so he is out of AT&T.
Bob

#: 72434 S17/TAPR NNC/DSP
    21-Mar-88  19:56:20
Sb: #72393-#Access Request
Fm: Bob McGwier N4HY 74615,1366
To: Franklin Antonio, N6NKF 76337,1365 (X)

The pulse stealer.  Currently, the hardware we are using gives us no way to
sample synchronously.  Thus to use recovered clock to make bit decisions at
the maximal opening of the eye I have to seriously oversample and arrange so
that when the phase passes 2PI I am at the maximum opening of the eye.  This
is the death of higher bit rates and costs dB in implementation loss.

Tom believes that because the disk was out of space on TOMCAT, that your ftp of
your PC based FFT stuff didn't make it.  I have yet to pull it over and try
it, would it be possible for you to take a look and see if it at least looks
like the right size?
Welcome.
Bob


*** There is a reply:   72462

*** More ***

#: 72462 S17/TAPR NNC/DSP
    22-Mar-88  00:28:26
Sb: #72434-Access Request
Fm: Franklin Antonio, N6NKF 76337,1365
To: Bob McGwier N4HY 74615,1366

Oh, the pulse stealer.  Yea.  That is a good idea.

Re TOMCAT, Grrrrrrrrrr.  I've had nothing but arpanetproblems getting there.
The gurus on my local arpa node tell me it has to do with arpanet-milnet
gateway congestion.  I've been trying for 2 days to ftp to tomcat and look at
the files to see if any of them ended up correct size.  I get either a message
that says "?failed to synchronize data connection" or "?failed somthingorother
TELNET connection".  Usually i can connect ok, but get the ?fail... when i give
the dir command.  I may resort to mailing a floppy!

*** More ***

#: 72455 S17/TAPR NNC/DSP
    21-Mar-88  22:38:52
Sb: #72393-#Access Request
Fm: Lyle Johnson, WA7GXD 76246,565
To: Franklin Antonio, N6NKF 76337,1365 (X)

8254/phase adjuster. super.

*** There is a reply:   72463

*** More ***

#: 72463 S17/TAPR NNC/DSP
    22-Mar-88  00:31:45
Sb: #72455-Access Request
Fm: Franklin Antonio, N6NKF 76337,1365
To: Lyle Johnson, WA7GXD 76246,565

Glad you liked it.  Say, that reminds me, last i talked to you, discussion was
about best method for putting error correction in computer memory for
satellite.  Which scheme did you end up with?

#: 72437 S17/TAPR NNC/DSP
    21-Mar-88  19:56:43
Sb: #72399-DSP SW
Fm: Bob McGwier N4HY 74615,1366
To: Alberto E. Zagni I2KBD 71360,3467 (X)

Alberto:
I will be in Europe in a couple of weeks but not in Italy this time.  We
have almost gotten disk #4 full.  This will be the first distributed by the
TAPR office.  There are several pieces of code on it and a couple to be
added yet.  I would like to add Barry's HF 300 BPS modem and Phil's
MACINTOSH talker program before we ship it out.  I hope that will be done
soon.  This past two weeks we have been doing AMSAT management business
(BLECCHH!) and working on PACSAT stuff and the DSP hardware and not doing
much in the way of putting software together for distribution.  Thanks for
reminding me it is about time to do all that.
Bob

#: 72476 S17/TAPR NNC/DSP
    22-Mar-88  10:18:14
Sb: #72183-#RE: HF Modem DSP #2
Fm: Barry McLarnon VE3JF 71470,3651
To: Bob McGwier N4HY 74615,1366 (X)

I don't know what to call it other than n-out-of-m signalling... how about
McLarnon signalling?  HAR!

I think we can't afford to waste power on a tone that does nothing but send
clock transitions.  Instead, we should use a a self-clocking baseband code that
provides lots of transitions in the data itself.  An early-late gate approach
should be workable.

*** There is a reply:   72502

*** More ***

#: 72502 S17/TAPR NNC/DSP
    22-Mar-88  21:26:46
Sb: #72476-RE: HF Modem DSP #2
Fm: Bob McGwier N4HY 74615,1366
To: Barry McLarnon VE3JF 71470,3651 (X)

Maybe you are right.  There should be a way to say one of the following k
tones will ALWAYS be present and is a way to choose amongst groups and also
these will give you clock.   Okay, I'll buy off on that just so long as I
get my pilot tone, even if at reduced dB.
Bob



#: 72477 S17/TAPR NNC/DSP
    22-Mar-88  10:18:46
Sb: #72193-#DSP 2001
Fm: Barry McLarnon VE3JF 71470,3651
To: Lyle Johnson, WA7GXD 76246,565 (X)

Lyle, the design sounds good to me.  I just want to make one finally plea on
behalf of more resolution in the A/D conversion.  Is there a way to accommodate
an upgrade to a 12-bit converter or the 14-bit TI TLC32041 without major
hacking on the board?  I'll grant that 8 bits is adequate for a lot of
applications, and that the faster conversion times are needed in some
instances.  But consider, for example, the possibility of demodulating a
multitone HF modem signal with a high peak-to-average ratio.  Add to the
considerable dynamic range of the signal itself, fade depths of 20-30 dB, the
difficulty of setting the gains so that the peak signal level exactly matches
the max. input level of the A/D, imperfect AGC, etc.  The 48 dB or so of
dynamic range provided by the 8-bit converter starts to look kinda puny.

Not everyone will need it, but it would be nice to have the hooks there for
upgrading to higher resolution, even for the Everyman's DSP Board.

Barry

*** There is a reply:   72529

*** More ***

#: 72529 S17/TAPR NNC/DSP
    23-Mar-88  02:57:37
Sb: #72477-DSP 2001
Fm: Phil Karn, KA9Q 73210,1526
To: Barry McLarnon VE3JF 71470,3651 (X)

I strongly second Barry's plea for additional dynamic range in the A/D.

Phil

#: 72480 S17/TAPR NNC/DSP
    22-Mar-88  11:23:38
Sb: #DSP SW
Fm: Alberto E. Zagni I2KBD 71360,3467
To: Bob McGwier N4HY 74615,1366 (X)

Dear Bob, thanks for news on disk 4, please remember to add some infos on
software disks 1,2 & 3. A final question: what's Phil Macintosh talker (I also
have a Mac II, you know... 8-) ) Best 73s, Alberto I2KBD

*** There is a reply:   72503

*** More ***

#: 72503 S17/TAPR NNC/DSP
    22-Mar-88  21:26:55
Sb: #72480-DSP SW
Fm: Bob McGwier N4HY 74615,1366
To: Alberto E. Zagni I2KBD 71360,3467 (X)

You probably have some of those talking icons or one of the funny noises
that appear on turn on or whatever,  Phil has a huge collction of them and
has written code to play them efficiently.  Phil has also written code that
inverts sideband.  A neat application of DSP to achieve spectrum folding.
i.e. you listen to the "wrong" sideband on the receiver and out of the D/A
comes "correct" sideband.
Bob

#: 72498 S17/TAPR NNC/DSP
    22-Mar-88  20:52:27
Sb: #Misc
Fm: Lyle Johnson, WA7GXD 76246,565
To: DSPers

Dan, Eric and I met in Eric's hospital room today and kicked around some ideas
re: DSP-2001.  I didn't get the schematics worked on as I had hoped, so asked
Cris to come by Thursday AM to pick things up.  I will be working on them a LOT
tonight and tomorrow night to have things ready for you all.

I will send copies to the previous list plus Mike Brock.  Remember, this is all
very preliminary stuff.  If any of the rest of you on this conference want to
be in this loop, let me know.

However, please keep in mind that this isn't going to be design by committee,
so some suggestions will probably not get implemented.  Still, I want all the
input I can get!

Dan's thoughts are running more and more away from the TMS320C25 for the next
widget (gotta look ahead, ya know!).  I am leaning a lot towards the Motorola
56001 even though I have a T.I. SWDS 320C25 development system installed in my
PC at work!

I will be getting together with Chuck and probably Dan later this week to hash
on some details, but it looks like things are geting a lot closer.

The evaluation PC layout disks came and this time they booted up on the AT at
the house.  As usual, there are some limitations but the package may prove to
be OK in the end.  Have to thrash it some more.

Lyle

*** There is a reply:   72509

*** More ***

#: 72509 S17/TAPR NNC/DSP
    22-Mar-88  21:47:30
Sb: #72498-Misc
Fm: Bob McGwier N4HY 74615,1366
To: Lyle Johnson, WA7GXD 76246,565

Hey whirlwind:
Looking forward to your schematics.  I am pushing very hard for us to be
able to bring the full scale model of PACSAT to Dayton, that's easy when you
are the size of a basketball!!  With all the fun stuff TAPR and AMSAT are
doing seems to me that it will be a very interesting year.  Can you believe
that it is entirely possible that within 12 months the amateur community
will have five new satellites between Surrey and AMSAT and a revolutionary new
technology to play with?  Exciting times, to hell with the good ole day
crap, we are in them.
Tell Dan if he hasn't received the FSK modem code by the time you read this
and ask him then I will one day mail it cause I'm sick of the US Snail.  He
and had fun talking about the pitfalls of FDM OOK and was presently
surprised that we had faced them and dropped back well before he returned
from his trip.  I think he is looking forward to having this new toy almost
as much as I am (it that is possible).
Bob

#: 72540 S17/TAPR NNC/DSP
    23-Mar-88  08:29:53
Sb: #72437-DSP SW
Fm: Barry McLarnon VE3JF 71470,3651
To: Bob McGwier N4HY 74615,1366

Bob, my modem code is "not ready for prime time".  I don't think a single 300
bps modem that remodulates back to 300 bps has enough useful functionality to
justify distributing just now.  I want to add the dual diversity stuff first...
coupla weeks I hope.

Barry